Eugene,

You have a lot of great ideas here, and I'm going to think about them more
before I offer any major comments.  However, I have a few observations to
add right now.

First, while I long for the fully object-oriented internal design that you
call for, such a design would require an object-oriented language, such as
C++.  Have all of the compatibility problems with C++ been worked out yet?
ANSI C (the current language of POV) is highly portable... is C++ just as
portable?

Eugene Arenhaus wrote:
> 
> POV 3 should not be used as direct ancestor for POV 4. Instead, POV 4
> should be developed with different principles in mind, aiming at
> greatest flexibility and easy extension of the product. Backward
> compatibility with previous versions should not be considered a major
> requirement: POV 3 is reaching its limit, it's time for breakthrough.
> 

I agree.  The POV 3 code (both the scriptiong language and the C source
itself) is somewhat inconsistent in places... I agree that a rewrite to
make it more modular would be great (maybe necessary).


>  Hierarchical, layered object model

I don't fully understand this hierarchal layered object model.  How would
this look when put to use?  I don't use MAX (no $$$), so I can't use that
as a reference.

> The proposed model, on the contrary, would allow all objects use any
> properties freely and interchangeably. The basic idea is layering
> (stacking) objects to achieve the final look. In a sense it is similar
> to MAX modifier stack, and to material maps used in POV.

I understand both of your examples (the MAX modifier stack and material
maps), but I don't understand the 'stacking' concept.  I can see, from an
OO point of view, the 'Sphere' class being inherited from the
'GenericObject' class... but would you go further and make it so you
could put a 'box' on top of a 'sphere' in a stack?  If so, what would
happen?  Would the box simply replace the geometry of the sphere but
keep everything else intact?

> Layered objects are containers for each other, and rely on the
> underlying layers to determine their final appearance. A sphere can
> compute its geometry but relies on the underlying texture object to
> determine its color. CSG object contains several geometry objects which
> in turn may be having their own textures. Blob object relies on
> underlying geometry or CSG objects to determine its own geometry.
> Textures may be composed of texture layers, and so on.

The blob example might look great in theory, but could be extremely
difficult to put into practice.  Current blobs only handle spheres,
cylinders (and maybe cones?).  Trying to base a blob on a SOR object
could make for some horrific math... and how would you base it on
an unknown object (since we wouldn't want blob to be changed when
a new object is added).

> 
> Bringing such consistency to the object model is of great importance
> for flexibility available to the end user. For example, currently we
> have texture maps and normal maps. (Add the height maps to it, these
> are still another thing.) Normal maps, in turn, have special parameters
> to control their slope, which are different from other control
> parameters in POV. With new ideology in action, we'll have only one map
> object to do all these things. We'd simply say that color channels must
> use one map, bump channel must use another map, and slope must use yet
> another map - or the same as others. (No more specially preparing image
> files for height fields.) What's yet more important, this approach
> would easily allow to map *any* parameter. For example, it'd be
> possible to have turbulence parameter varying but a map, having
> turbulence gradients (an actual user request), or having a variable
> mapped IOR, for hot-air effects, using the same mechanism as with other
> mapping.

Some of these make-the-maps-consistent ideas could actually be implemented
relatively easily in POV 3 (at the cost of backwards compatibility).  In
fact, some of them have.  The superpatch has the image_pattern pattern,
which allows you to use a bitmap image as a POV pattern, and it also
has the ability to generate a bitmap (for use in a heightfield) from a
pattern.  I think these features need to be fully merged together,
though, as you suggest.

> Effective implementation of this principle would require a certain
> change in the set of POV primitives: they would become simpler and
> smaller; instead of being individual big machines capable of doing many
> things they would be more like machine parts that can do only one
> little action but also be used to assemble many machines. For example,
> instead of having separate object for a height field, there would be a
> special displacement map primitive applicable to geometry, and
> turbulence parameter could be handled as separate primitive as well,
> applicable to textures and texturable in turn. Possibilities are
> endless.

I disagree with doing away with the height field.  The current height
field is much faster than a general displacement map would be.  There are
many speed shortcuts that can be taken when rendering the displacement
map of a plane that could not be applied to the general displacement
map.  Plus, implementing the general displacement map requires
implementing a primative->triangle conversion for all objects (including
CSG) which nobody has done for POV yet.

>  Implementation issues
> 
> Instead of multiple unique objects to handle, it's suggested to use a
> single consistent object model for everything from geometry to
> textures.

I disagree.  I think a distinction must be made between objects, materials,
pigments, finishes, ...

Looking at it from OO again, "a sphere HAS A material" is true, not
"a sphere IS A material".  However, "a sphere IS A object" would be
correct.

While the concept of everything being the same is appealing (and I
might like it more after some further thought), my initial thought
is that it would be inefficient and confusing.

More comments to come later.

-Nathan

Post a reply to this message